An exploration of how next-intl can adapt better for ppr, dynamicIO and rootParams (see #1493).

Centralized validation of [locale] segment with dynamicParams = false

If params can be read statically, we could use dynamicParams = false to return a 404 for unknown locales (see d1a0308).

However, it seems like this isn't a good idea to introduce yet:

1. Currently, providing locales statically is a bit cumbersome, so this would definitely rely on rootParams. If that's the case, this could simplify the usage for the common case, but maybe we need to cover the case for unknown locales earlier in the docs.
2. dynamicParams is not compatible with dynamicIO—and maybe never will:

"dynamicParams" is not compatible with `nextConfig.experimental.dynamicIO`. Please remove it.

However, it seems like Next.js is working on an alternative to dynamicParams = false. With this, maybe we'll have a reasonable solution for centralized validation of the [locale] segment.

EDIT: I've opened vercel/next.js#84991 for further discussion.

Usage of setRequestLocale

Calling setRequestLocale within a 'use cache' boundary doesn't seem to work. We need to wait for rootParams to get rid of this API.

Reading the locale param without suspending

Currently not easily possible, waiting for an alternative to dynamicParams = false: vercel/next.js#71927.

What did work in my test though is to use 'use cache' on both the layout and page entry point. This might not fit your application though and furthermore makes it impossible to read request-specific params in components. EDIT: It only works in dev, not when building the app.

Another use case to be tested would be mixing a statically known [locale] param with a dynamic child page (see https://nextjs.org/blog/our-journey-with-caching#partial).

Importing of JSON messages

Dynamic imports currently cause an error: vercel/next.js#72589.

Effect of use(…) and await

For the APIs that next-intl offers, these seem to not require a suspense boundary for async data—that's helpful.

Effect of client-side hooks on caching

Hooks like useParams, useSelectedLayoutSegment and usePathname work fine in development but error out during the build when used in a dynamic segment like [locale], asking for a suspense boundary or 'use cache'. Not sure what the expected behavior is, but there's definitely an inconsistency here. See vercel/next.js#72756.

EDIT: This would probably also require a replacement for dynamicParams = false.

Conclusion

1. For a setup with i18n routing there are too many pieces missing currently
2. For a setup without i18n routing ppr and dynamicIO might work (but requires feat!: Remove default of now={new Date()} from NextIntlClientProvider for usage with format.relativeTime (preparation for dynamicIO) #1536)

However, it seems like with #1412 users can adopt these modes without any changes necessary in next-intl.

Once rootParams is a thing, we can:

1. Adapt docs
   1. Read from rootParams in i18n/request.ts.
   2. Use getLocale() instead of reading from params in components. This can be strongly-typed and potentially overridden.
   3. getTranslations({locale: …}) should only be relevant for overriding locales, not for enabling static rendering. We might want to re-introduce a sync ({locale}) arg for this use case though.
   4. Clarify the job of the middleware (see docs for matcher)
2. Release minor version
   1. Re-introduce ({locale}) for overriding a locale (this is now only an edge case for apps that render with multiple locales simultaneously on the server). Also: Warn if ({locale}) is passed to getRequestConfig but not read.
   2. We don't rely anymore on the hardcoded [locale] segment and also don't need to bump the peer dependency aggressively once this API is introduced since next-intl doesn't read from it.
   3. Deprecate await requestLocale once rootParams is stable and supported for some time. Consider that users on older Next.js versions will still rely on this until they've upgraded to a Next.js version that supports rootParams—therefore don't deprecate too aggressively.
   4. Deprecate setRequestLocale